Introduce TinyZAP, a new on-disk ZAP format between MicroZAP and FatZAP. MicroZAP is limited to 1xuint64 values and 49-char keys, any wider entry forces a full FatZAP upgrade. TinyZAP avoids this for the common case of multi-integer values (e.g., Lustre FIDs) and long key names.

Signed-off-by: Akash B akash-b@hpe.com

Motivation and Context

This PR introduces TinyZAP, a new on-disk ZAP format that sits between MicroZAP and FatZAP in the ZAP format. TinyZAP extends MicroZAP to efficiently handle multi-word values and long key names without the overhead of a full FatZAP upgrade.
The primary motivation is workloads like Lustre that store multi-integer values (e.g., FIDs: 2-3 x uint64_t) or long filenames in ZAP objects. Previously, these always created a FatZAP, consuming significantly more on-disk space and memory than necessary.

ZAP Format Hierarchy (After This Change)
MicroZAP -> TinyZAP -> FatZAP
However, internally TinyZAP is also a MicroZAP (but an extended format). TinyZAP is an in-place extension of MicroZAP that supports multi-integer values and longer key names without upgrading to FatZAP.

Description

TinyZAP reuses the existing mzap_phys_t block format.
Three previously reserved bytes in the 64-byte header are repurposed as independent uint8_t fields:

typedef struct mzap_phys {
    uint64_t mz_block_type;   /* ZBT_MICRO */
    uint64_t mz_salt;
    uint64_t mz_normflags;
    uint8_t  mz_flags;        /* MZAP_FLAG_TINY Flag to distinguish from microzap */
    uint8_t  mz_chunk_shift;  /* log2(chunk): 6=64B, 7=128B, 8=256B */
    uint8_t  mz_value_ints;   /* num_integers; stride = mz_value_ints * 8 */
    uint8_t  mz_pad1;         /* zero */
    uint32_t mz_pad2;         /* zero */
    uint64_t mz_pad3[4];      /* zero */
    mzap_ent_phys_t mz_chunk[]; /* variable-size chunk array */
} mzap_phys_t;

When mz_flags == 0, the block is a plain MicroZAP. When MZAP_FLAG_TINY (bit 0) is set, the TinyZAP layout applies. Each chunk slot is a tzap_ent_phys_t:

[0 .. stride-1]       value blob  (mz_value_ints × uint64_t)
[stride .. stride+3]  cd          (uint32_t)
[stride+4 .. chunk-1] name        (NUL-terminated string)

Supported chunk sizes and resulting geometry (examples only).

Supported chunk sizes and resulting geometry (examples only).
name_len = chunk - stride - 4  (stride = mz_value_ints * 8)

chunk | stride | name_len | integers | use-case
------+--------+----------+----------+--------------------------------------
  64  |    8   |    52    |    1     | 1×uint64, name up to 51 chars
  64  |   16   |    44    |    2     | 2×uint64 (Lustre FID)
  64  |   24   |    36    |    3     | 3×uint64
  64  |   32   |    28    |    4     | 4×uint64
  64  |   56   |     4    |    7     | max stride for chunk=64
 128  |    8   |   116    |    1     | 1×uint64 + long name
 128  |   16   |   108    |    2     | 2×uint64 + long name
 128  |   48   |    76    |    6     | 6×uint64 (3×Lustre FID)
 128  |  120   |     4    |   15     | max stride for chunk=128
 256  |    8   |   244    |    1     | 1×uint64 + very long name
 256  |   16   |   236    |    2     | 2×uint64 + very long name
 256  |  128   |   124    |   16     | 16×uint64 (wide value, medium name)
 256  |  248   |     4    |   31     | max stride for chunk=256
 ...

Note: stride=8 with chunk=64 is skipped by tzap_try_promote() because it provides only 2 bytes more than MicroZAP. Chunk=128 is the minimum for stride=8. chunk=64 is only used when stride >= 16 (num_integers > 1).

Other details on ZAP upgrade conditions:

MicroZAP -> TinyZAP Conditions:
Promotion is attempted automatically on the first zap_add() when the entry fails the plain MicroZAP constraints. All of the following must hold:

integer_size == 8 (only uint64_t values supported)
stride = num_integers × 8 >= 8
At least one chunk size (64/128/256) can accommodate: stride + 4 + TZAP_MIN_NAME_LEN <= chunk && strlen(key) < TZAP_NAME_LEN(chunk, stride)
The pool featurecom.hpe:tinyzapis enabled

The stride is stamped once on the first qualifying add and cannot change. The smallest fitting chunk is selected automatically.
For stride=8, promotion is also allowed on a populated MicroZAP: existing entries are re-encoded in-place via tzap_reencode_micro_to_tiny(), which re-packs the fixed 64-byte MicroZAP slots into the wider TinyZAP chunk format using a buffer.

TinyZAP Chunk Upgrade (in-place, stays TinyZAP)
When a new key is too long for TZAP_NAME_LEN(chunk, stride) but fits a larger chunk size, tzap_try_chunk_upgrade() re-packs all entries into the new chunk size without upgrading to FatZAP. The chunk can grow from 64->128 or 128->256. The block is grown if needed (up to zap_micro_max_size).

TinyZAP -> FatZAP Conditions:
A FatZAP upgrade is forced when any of the following occur:

integer_size != 8
num_integers != stride / 8(value width mismatch with stamped stride)
Key is too long for TZAP_NAME_LEN(256, stride)(no chunk fits)
All chunk slots are full and the block cannot grow further

During mzap_upgrade(), existing TinyZAP entries are re-encoded into FatZAP leaf blocks via tzap_upgrade_entries(). This function reads the original block size from the sz snapshot taken before fzap_upgrade() changes db_size to 16KB, preventing iteration over ghost slots.

Plain MicroZAP -> FatZAP (Unchanged)
If TinyZAP promotion fails (no fitting chunk, integer_size != 8, geometry mismatch), the existing MicroZAP -> FatZAP path is taken.

others:
SPA Feature Flag: com.hpe:tinyzap
A new pool feature, SPA_FEATURE_TINYZAP (com.hpe:tinyzap) is introduced:

1. Not read-only compatible: pools with TinyZAP objects cannot be imported by software that does not support this feature, even read-only.
2. Flags: (ZFEATURE_FLAG_MOS) It's decided that the MOS entries need not use TinyZAP.
3. The feature becomes active the first time a TinyZAP object is created and returns to enabled when all TinyZAP objects have been removed or upgraded to FatZAP.

How Has This Been Tested?

Added simple tests:
Functional test suite which tests or exercises MicroZAP->TinyZAP, chunk upgrade, TinyZAP->FatZAP, remount, readdir, collision, feature flag, etc.

Before the patch using Lustre (FatZap):

# mkdir testdir1 && touch testfile1
# du --si test*
100k    testdir1
1.1k    testfile1

Performance:

416 tasks, 1248000 files/directories
SUMMARY rate: (of 3 iterations) (op/sec)
   Operation                     Max            Min           Mean        Std Dev
   ---------                     ---            ---           ----        -------
   Directory creation          40183.030      33505.043      37718.225       3666.264
   Directory stat             150247.149     140618.623     145442.903       4814.295
   Directory removal           69091.318      55062.863      60385.987       7601.242

Total space taken by 1.25 million directories: Total Size: 117.7G (98.86 KB/Inode)

After this patch using Lustre (TinyZap):

# mkdir testdir1 && touch testfile1
# du --si test*
1.1k    testdir1
1.1k    testfile1

Total space taken by 1.25 million directories: Total Size: 3.7G (3.09 KB/Inode)

Performance:

416 tasks, 1248000 files/directories
SUMMARY rate: (of 3 iterations) (op/sec)
   Operation                     Max            Min           Mean        Std Dev
   ---------                     ---            ---           ----        -------
   Directory creation         106757.610     100377.356     104069.288       3306.408
   Directory stat             296205.362     225769.238     262180.060      35278.604
   Directory removal          155819.816     134755.537     145367.644      10533.050

These were the summary of the results overall:
For draid2:9d:12c:1s-0 (flash MDT and 4 OSTs):
Directory creation improved by +176% - over 2.75x faster, exceeding 100K ops/sec
Directory removal improved by +141% - over 2.4x faster, exceeding 145K ops/sec
Directory stat improved by +97% at peak - nearly 2× faster, approaching 300K ops/sec

Space Efficiency:
Almost 99% reduction in empty directories.
TinyZap (1-2 KB) vs. FatZAP (100-130 KB).
For 1.25 million directories (TinyZap: 3.7G (3.09 KB/Inode) vs. FATZap: 117.7G (98.86 KB/Inode)), ~32x reduction

TODO:

1. Fix the checkstyle and other rebase-related issues.
2. I have some of the local bash tests, which I probably will add some of to zfs-tests in the next push.
3. Running a few tests with Lustre, may delay a little here.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.